Throughout this article the word "schema" has been
used as a general term to describe the database architecture and its
objects. However, in SQL Server the term schema, or more formally Database Object Schema,
refers to the namespace, or container, in which database objects
reside. Inside the database object schemas are database objects, such as
tables, views and stored procedures, which can be grouped together
logically. This offers a way to organize your database objects and
control access to them at a group level.
When a user is denied access
to a database object schema, they cannot view or access any of the
database objects within it. This offers a level of obscurity to portions
of the overall database schema design and can be used to separate
highly sensitive data from less sensitive data. Figure 1 illustrates how a user may have access to one database object schema, in this case the default database object schema of dbo, while being denied to all objects within another database object schema, here, the Income_Schema database object schema.
Database object schemas offer
an effective method of protecting sensitive data through separation,
and can also make permission management less of a headache to the DBA.
To create a database object schema in a database the CREATE SCHEMA method will be executed in SQL Server Management Studio. The following is an example of the syntax of this method:
CREATE SCHEMA [Schema Name] AUTHORIZATION [Schema Owner]
This method's arguments are:
Schema name: This is the textual reference to the database object schema.
Authorization:
This is the textual reference to the schema owner. This argument is
optional. When this argument is not included the user creating the
database object schema is set as the object owner.
In the HomeLending database, the only role that we want to allow to modify database objects, or set permissions, in the Income_Schema schema is the Database Role of db_owner. Therefore, the statement that was used to create the Income_Schema schema includes the AUTHORIZATION argument, as shown in Listing 1.
Having created the database object schema, we can use the GRANT, DENY and REVOKE
statements to manage permissions to that schema, in a similar fashion
to the manner in which we've previously used them to manage permissions
to database objects.
An example of the syntax used to grant SELECT, INSERT and UPDATE privileges to the Sensitive_high Database Role for the Income_Schema database object schema, is shown in Listing 2.
Notice the two colons (::)
used in reference to the schema. This is a scope qualifier. A scope
qualifier defines that the permissions are restricted to a specific
object type. In this case, we defined the object type to be a schema and
then reference the schema on which we wish to grant permissions.
When referencing database
objects, it is good practice to refer to them with their fully qualified
name, which will include a reference to the database object schema in
which the object resides. When the database object schema is not
included, SQL Server will search the database user's default database
object schema to try to find the database object that is being
referenced; if the database object is not found an error will be
returned stating that the object is invalid.
Listing 3 shows a sample query in which the fully qualified names of the tables in the default database object schema, which is dbo, and the Income_Schema schema, are referenced.
